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Remarks 

In the Office Action dated June 7, 2006 ("Office Action"), Claims 1, 2, 4-6, 
12-16, 19-24, 29-32 and 34-36 were rejected and Claims 3, 7-11, 17, 18, 25-28, 
33 and 37 were objected to. In the Amendment set forth above, Claims 1,12, 
20, 29, and 34 are amended and the remaining Claims are unchanged. In view 
of the amendments to the Claims and the comments set forth below, it is 
re s p e ctful l y s ubmitt e d th o Cla i ms arc in condition for Al l owanc e . 

1 . Claim 1 4 was objected to for failing to provide proper antecedent basis for 
the phrase "other linked request" in line 6. It is believed this objection was 
inadvertently maintained from the previous Office Action dated 12/29/2005. In 
response to that previous Office Action, an amendment submitted March 21, 
2006 inserted the word "any" before the subject phrase in line 6 of Claim 14, as 
shown in the above Claim set. If this objection is not withdrawn, more 
clarification is requested regarding this objection. 

2. Claims 1 , 2 f 4-6, 1 2-1 6, 1 9-24, 29-32, and 34-36 were rejected under 35 
USC §1 03(a) as being unpatentable over U.S. Patent No. 6,434,641 to Haupt et 
al. ("Haupf ) in view of U.S. Patent No. 6,973,550 to Rosenbluth et al. 
("Rosenbluth"). This rejection is respectfully traversed. 

First, Claim 1 is considered. As amended, Claim 1 now recites that if 
multiple requests are requesting the same data, a respective linked list is created 
to record those requests. This linked list is created without regards to types of 
the requests . (Claim 1 step b.) That is, a determination as to whether to add a 
request to a linked list is not based on the type of the request. This type of 
operation is described throughout Applicants' Specification. As one example, 
Applicants' Specification states: 
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Before a request for a cache line can be presented to SCD 100, cache 
control logic 202 forwards information associated with the cache miss to 
Local Tracker (LT) control logic 203. LT control logic creates a request 
entry for the request within a storage device referred to as Local Tracker 
(LT) 212....[E]ach LT entry includes a link field 228 that is provided to link 
the current LT entry to any subsequently created entry associated with a 
request for the same cache line. In one embodiment the link field may be 
set to the index value that identifies a latter-created LT entry, as will be 
described below. Requests are linked in this manner to order the requests 
for the same cache line according to time-order. (Specification page 14 
lines 28-31 and page 15 lines 17-22.) 



The foregoing passage describes that according to Applicants' invention, 
any request that is directed to a same cache line in main memory (i.e., the SCD) 
as one or more previously-issued pending requests is added to the LT and linked 
to one of these previous requests. This occurs without regard to request type. 
This linking of all types of requests in this manner prevents memory thrashing 
and the occurrence of deadlock scenarios. (Applicants' Specification page 6 
lines 16-17.) 

In contrast to Applicants' mechanism for linking requests, the mechanism 
is Haupt is request-type dependent as follows: 



"Certain types of requests, including fetch requests for requesting read 
data from memory, are further provided to Defer CAM Logic... the address 
signals associated with any fetch request are always compared to the 
address signals associated with every valid request stored within CAM 
702.... a favorable comparison occurs when the address signals of the 
current request are the same as the address signals associated with any 
request stored in CAM 702. When this occurs, the current request is 
linked via the address link stored in Field 716 to the CAM address storing 
the most recent of the other requests." (Haupt column 13 lines 34-36, 
column 18 lines 61-64, column 19 lines 9-1 1 and 19-21, emphasis added.) 

Thus, in Haupt, only fetch requests need be linked to other requests. Haupt 
therefore does not teach Applicants' mechanism described in amended Claim 1 
that links requests irrespective of request type. 
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Rosenbluth, like Haupt, does not teach a mechanism for linking requests 
irrespective of request type. Rosenbluth teaches linking only fetch requests that 
are soliciting the same data as a previously-issued pending write request, as 
follows: 

"...the controller 108 can implement logic that identifies when a read 
command requests memory addresses to be accessed for a queued 114 
write command." (Rosenbluth column 2 lines 32-34.) 

This is reiterated in Rosenbluth as follows: 

"As shown in FIG. 8, for received 152 read commands, a process 150 
determines 154 the buckets) associated with the read and determines 
156 whether the bucket(s) correspond to a bucket associated with a 
queued write command. If so 158, the process 150 can queue 162 the 
read command with a link to a write command that should be issued to 
memory before the read command." (Rosenbluth column 6 lines 17-20.) 

Thus, Rosenbluth, like Haupt, does not teach, or even suggest, a mechanism for 
creating a linked list of requests without regard to types of requests. 

In addition to the foregoing, there is no motivation to make the cited 
combination of references. The Examiner states that one would be motivated to 
modify the request linking system of Haupt with the linking system of Rosenbluth 
because then the retrieval of future data will be coherent. (Office Action page 4 
line 4.) However, the Haupt system utilizes a directory and the associated 
directory logic to maintain data coherency. (See, for example, Haupt column 14 
lines 11-12 and the description of the directory logic 628 of Figure 6.) Thus, the 
Haupt system does not require any additional request linking mechanism of a 
type described by Rosenbluth or any other reference to maintain data coherency. 
For at least this reason, there is no motivation to combine any aspect of 
Rosenbluth with Haupt 

Further to the foregoing point, there is no motivation to combine any 
aspectof the Rosenbluth linked list with the linking mechanism of Haupt for at 
least the following additional reasons: 
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a. ) The Haupt linked list serves an entirely different purpose than any 
linking of requests performed by Rosenbluth. In Haupt, the linking of fetch 
requests is performed "... [t]o improve system performance by preventing the 
presentation of the subsequent request [for the same data] to MCL 235A...". 
(Haupt column 18 lines 60-61 .) In contrast, the Rosenbluth system links 
requests to ensure that a read request does not by-pass an earlier-issued write 
request for the same data such that data coherency is not maintained. 
(Rosenbluth column 2 lines 56-63.) Thus, the purpose of request linking in Haupt 
is e nt i r e ly d i ffer e nt from that d e scribed by Rosenbluth. 

b. ) In Haupt, the fetch requests are linked to a previously-issued request 
for the same data. The previously-issued request may be another fetch request 
or an I/O overwrite request. (Haupt column 16 lines 24-29.) In contrast within 
the Rosenbluth system, a fetch is always associated with a previously-issued 
write request (Rosenbluth column 3 lines 8-10.) Thus, the types of requests 
that are being linked in Haupt are different from those being linked in Rosenbluth. 

In view of the foregoing, one skilled in the art would not be motivated to 
make the cited combination of references for at least the following reasons: 

a. ) The Haupt system maintains data coherency through the use of 
directory logic and does not require any additional mechanism such as any 
aspect of the Rosenbluth request linking system to maintain coherency; 

b. ) The linking of requests in Haupt is done for an entirely different reason 
than in Rosenbluth; and 

c. ) The linking of requests in Haupt is done in an entirely different way 
than in Rosenbluth and by linking different types of requests than are linked in 
Rosenbluth. 

For at least the foregoing reasons, one skilled in the art would not be 
motivated to make any attempt to combine aspects of the Rosenbluth request 

llr%lsir\r* ryiA^ Kqn{«m intn 4 *\ tT>t f\rn /\f Uqi u~>t ..Daiaa th**i tft/oi ilH Fiofr o^mo n > loofi it 
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purpose, and it is unclear if, or how, such a system would even operate. 
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To summarize, amended Claim 1 is allowable over the current rejection for 
at least the reasons that Claim 1 describes a system wherein linking of requests 
is accomplished without regard to request type. None of the cited references 
teach or suggest this aspect of the invention. Moreover, no motivation exists to 
make the cited combination of references, and a prima facie case of obviousness 
has therefore not been presented. Thus, Claim 1 is allowable over the current 
rejection, which is improper, and should be withdrawn. 

C l aim s 2 and 4- 6 d e p e nd from C l a i m 1 , and aro a ll owable for at loast th e — 

reasons set forth in regard to Claim 1 . These Claims include additional aspects 
not taught or suggested by the cited combination of references. 

Independent Claim 12 has been amended to include aspects of 
Applicants' invention that are similar to those discussed above in regard to Claim 
1 . For at least reasons that are similar to those discussed above with respect to 
Claim 1, Claim 12 is allowable over this rejection. 

Claims 13-16, and 19 depend from Claim 12, and are allowable for at least 
the reasons set forth in regard to Claim 12. These Claims include additional 
aspects not taught or suggested by the cited combination of references. 

Independent Claims 20, 29 and 34 have been amended to include aspects 
of Applicants 1 invention that are similar to those discussed above in regard to 
Claim 1 . For at least reasons that are similar to those discussed above with 
respect to Claim 1 , these Claims are allowable over this rejection. 

Claims 21-24, 30-32, and 35-36 depend from a respective one of 
independent Claims 20, 29, and 34 and are allowable for at least the reasons set 
forth in regard to Claim 1 . These Claims include additional aspects not taught or 
suggested by the cited combination of references. 
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3. Applicants' appreciatively acknowledge the indication of allowable subject 
matter with respect to Claims 3, 7-1 1,17, 18, 25-28, 33, and 37. In view of the 
amendments and comments set forth above, it is respectfully submitted that all 
Claims are now in condition for allowance. 
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Conclusion 



In the Office Action dated June 7, 2006, Claims 1 , 2, 4-6, 12-16, 19-24, 
29-32 and 34-36 were rejected and Claims 3, 7-1 1 , 1 7, 1 8 F 25-28, 33 and 37 
were objected to. In the Amendment set forth above, Claims 1 , 12, 20, 29, and 
34 are amended and the remaining Claims are unchanged. In view of the 
amendments to the Claims and the comments set forth above, it is submitted that 

the Claims are in condition for allowance, and a Notice of Allowance is 

respectfully requested. If the Examiner has any questions or concerns regarding 
the foregoing, a call to the undersigned is encouraged and welcomed. 

Respectfully submitted, 



Beth L McMahon 
Attorney for Applicants 
Reg. No. 41 ,987 
Tele No. (651)635-7893 

Unisys Corporation 

M.S. 4773 

P.O. Box 64942 

St. Paul, MN 55164-0942 
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